Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pem-mime-03.txt < prev next >

Wrap

Text File | 1993-10-26 | 40.7 KB | 1,235 lines

Network Working Group Steve Crocker Internet Draft Ned Freed <draft-ietf-pem-mime-03.txt> Jim Galvin Sandy Murphy Marshall Rose MIME-PEM Interaction Oct 15, 1993 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 2. Abstract This memo defines a framework for interaction between MIME and PEM services. MIME, an acronym for "Multipurpose Internet Mail Extensions", defines the format of the contents of Internet mail messages and provides for multi-part textual and non-textual message bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message encryption and message authentication/integrity services for Internet mail messages. draft MIME-PEM Interaction Oct 1993 3. Introduction An Internet electronic mail message consists of two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to MIME [2]. MIME does not provide encryption or authentication/integrity services. PEM [3-6] allows encryption and authentication/integrity enhancements to be applied to the contents of electronic mail messages but does not provide message structuring or type labelling facilities. This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion. The resulting combined service provides encryption and authentication/integrity services for single-part and multi- part textual and non-textual messages. We refer to the authentication/integrity service as a signature. The services of encryption and signature are separated. This differs from the service provided by [3], in that the encryption privacy enhancement in [3] also computes a signature of the message. To take full advantage of the functionality provided by MIME, canonicalization and transfer encoding operations are removed from the privacy enhancement and left to the MIME agent. The content domain header, defined in [3], is not included, as its functionality is subsumed by MIME. Transmission of certificate and certificate revocation lists is separated from the privacy enhancement. The message types no longer need be mentioned in the headers, as the information they impart is contained in the content types. The requests and responses of [6] are provided for in new content types. This represents a departure in mechanism, although not in effect, from the procedures identified in [3]. Expires Apr, 1994 [Page 2] draft MIME-PEM Interaction Oct 1993 MIME-PEM interaction is provided for by defining six new MIME content types: application/pem-keys, application/pem- signature, application/pem-encrypted, application/quoted-mime- entity, application/pem-request and application/certdata. The MIME-PEM interaction also uses another new MIME type, multipart/headerset, proposed by David Crocker. The relationship between MIME and PEM is described in terms of two functions, message composition and message delivery. The new content types have two different purposes. The first four types (application/pem-keys, application/pem-signature, application/pem-encrypted and application/quoted-mime-entity) are used to transmit and receive privacy enhanced messages and are always encapsulated in a multipart/headerset body part. The last two types (application/pem-request and application/ certdata) are used to transmit requests for certificate operations (retrieval, certification, revocation lists retrieval, etc.) and the responses to those requests. These two content types are independent body parts, not required to be encapsulated in any other body part. The two groups of content types are discussed in the two sections following. 4. Definition of new enhancement Content Types 4.1. Multipart/headerset Content Type Definition (1) MIME type name: multipart (2) MIME subtype name: headerset (3) Required parameters: boundary (4) Optional parameters: none (5) Encoding considerations: Either 7bit, 8bit, or binary encoding may be used, depending on the nested part encodings and transport limitations. (6) Security Considerations: see [3] Expires Apr, 1994 [Page 3] draft MIME-PEM Interaction Oct 1993 The headerset subtype of multipart always contains at least two body parts, where the first body part gives instructions in some way for the processing of all the body parts. In this use of the headerset subtype, there are always two body parts. The first part describes the privacy enhancement which was applied to the second body part. The first part's content type is application/pem-signature or application/pem-keys. The second body part contains a body part which contains the privacy-enhanced content. The second part's content type is either application/pem-encrypted, if the requested privacy enhancement is encryption, or application/quoted-mime-entity, if the requested privacy enhancement is signature. The syntax and semantics of the boundary parameter is defined in [2]. 4.2. Application/pem-keys Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-keys (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production for <pemkeys>, which differs from the <pemhdr> in [3] in that neither the <crlhdr> nor the fields conveying certificates or related exclusively to signature are a part of the production. (The certificate fields appear in the application/certdata content type, see Section 5.2). The <contentdomain> field is also eliminated. The <proctype> field is replaced by the <version> field, as the message types included in <proctype> are imparted by the content type name of the body part. The productions <dekinfo>, <origid-asymm>, Expires Apr, 1994 [Page 4] draft MIME-PEM Interaction Oct 1993 <origid-symm>, <recipflds> and <keyinfo> are as defined in section 9 of [3]. <pemkeys> ::= <version> <dekinfo> (1*(<origkeyflds> *<recipflds>)) ; symmetric case /((1*<origkeyflds>) *(<recipflds>)) ; asymmetric case <version> ::= "Version" ":" "5" CRLF <origkeyflds> ::= <origid-asymm> [<keyinfo>] ;asymmetric / <origid-symm> [<keyinfo>] ;symmetric This content type must be used as the first part of a multipart/headerset content type. It may not be used in any other context. 4.3. Application/pem-signature Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-signature (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production for <pemsig>, which differs from the <pemhdr> in [3] in that neither the <crlhdr> nor the fields conveying certificates or related exclusively to encryption are a part of the production. (The certificate fields appear in the application/certdata content type, see Section 5.2). The <contentdomain> field is also eliminated. The <proctype> field is replaced by the <version> field, as the message types included in <proctype> are imparted by the content type name of the body part. The productions <keyinfo>, <micinfo>, Expires Apr, 1994 [Page 5] draft MIME-PEM Interaction Oct 1993 <recipflds>, <origid-asymm> and <origid-symm> are as defined in section 9 of [3]. <pemsig> ::= <version> (1*(<origsigflds> *<recipflds>)) ; symmetric case /((1*<origsigflds>) *(<recipflds>)) ; asymmetric case <version> ::= "Version" ":" "5" CRLF <origsigflds> ::= <origid-asymm> [<keyinfo>] <micinfo> ;asymmetric / <origid-symm> [<keyinfo>] ;symmetric This content type must be used as the first part of a multipart/headerset content type. It may not be used in any other context. 4.4. Application/pem-encrypted Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-encrypted (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: The encryption will produce binary data and may need to be encoded for transport. Any transport-compatible encoding capable of accommodating binary data may be used. A base64 encoding will be sufficient for all transport systems. (6) Security Considerations: see [3] The content of the application/pem-encrypted is an encrypted valid MIME object. Because it is encrypted, the canonical form of this content type is any arbitrary data. This content type must be used as the second part of a multipart/headerset content type. It may not be used in any Expires Jan, 1994 [Page 6] draft MIME-PEM Interaction Jul 1993 other context. 4.5. Application/quoted-mime-entity Content Type Definition (1) MIME type name: application (2) MIME subtype name: quoted-mime-entity (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: If the quoted mime body part has a quoted printable, 7bit, or base64 transfer encoding indicated, the transfer encoding of this body part should be 7bit to avoid nested encodings. Otherwise, any transport-compatible encoding capable of accommodating the content type of the quoted mime body part may be used. (6) Security Considerations: see [3] The application/quoted-mime-entity content is constrained to be a valid MIME object. The content of that body part must be in the canonical form for its content type. This content type must be used as the second part of a multipart/headerset content type. It may be used in any other context, as well. The application/quoted-mime-entity content type may on first inspection appear to be superfluous since the content it contains is itself constrained to be a valid MIME object. However, the use of application/quoted-mime-entity serves a vital function: it protects the inner MIME object from any changes that might be performed by messaging gateways. Such changes frequently disrupt header and boundary information, which in turn would lead to integrity check failures. Expires Apr, 1994 [Page 7] draft MIME-PEM Interaction Oct 1993 The use of application/quoted-mime-entity ensures that if a gateway is compelled to make encoding changes it will do so on the application/quoted-mime-entity object as a whole. Such encoding changes, if done properly, will leave the application/quoted-mime-entity content entirely intact. The application/quoted-mime-entity type may be generally useful outside PEM, as well. We intend for this to be a type that could be used anywhere in a MIME object and not restricted to PEM. 5. Definition of new certificate Content Types 5.1. Application/pem-request Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-request (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production. <request> ::= <version> <version> ::= "Version" ":" "5" CRLF (<subject> / <issuer> / <certification>) <subject> ::= "Subject" ":" <asymmid> CRLF <issuer> ::= "Issuer" ":" <asymmid> CRLF <certification> ::= "Certification" ":" <encbin> CRLF The purpose of this body part is to transmit a request. The request can be "Certification", which requests certification of a self-signed certificate, or "Subject", which requests the Expires Apr, 1994 [Page 8] draft MIME-PEM Interaction Oct 1993 certificate chain corresponding to a subject identified by a distinguished name, or "Issuer", which requests the revocation list chain issued by an issuer identified by a distinguished name. The "Subject" and "Issuer" fields each contain a value of type Name, encoded according to the Basic Encoding Rules, then in ASCII, as for the "Originator-ID-Asymmetric" field of [3]. In each case, the response can be transmitted in an application/certdata content type. This type is intended to provide for the requests described in [6]. The key certification request and CRL-retrieval request are provided for directly. The CRL-storage request is provided for by transmitting the CRL's to be stored in an application/certdata content type. 5.2. Application/certdata Content Type Definition (1) MIME type name: application (2) MIME subtype name: certdata (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production built on top of the definitions in section 9 of [3]. <certdata> ::= <certchain> / <crlchain> <certchain> ::= <version> (<cert> *([<crl>]<cert>)) <crlchain> ::= <version> 1*(<crl>[<cert]) <cert> ::= "Certificate" ":" <encbin> CRLF <version> ::= "Version" ":" "5" CRLF Expires Apr, 1994 [Page 9] draft MIME-PEM Interaction Oct 1993 This content type is used to transfer certificate or certificate revocation list information. This information is entirely independent of any particular enhanced message. (Note that the converse is not true: the validity of an enhanced message cannot be determined without the proper certificates or current CRL information.) As such, the application/pem- certdata content type is an independent body part. It is not used in a multipart/headerset context containing PEM enhanced messages. The <certchain> production contains one certificate chain. Each certificate chain starts with a certificate and continues with the certificates of subsequent issuers. Each issuer listed is presumed to have issued the preceding certificate. For each issuer, a CRL may be supplied. A CRL in the chain belongs to the immediately following issuer. Therefore, it potentially contains the immediately preceding certificate. The <crlchain> production contains one certificate revocation list chain. The CRLs in the chain begin with a requested CRL and continue with the CRLs of subsequent issuers. The issuer of each CRL is presumed to have issued a certificate for the issuer of the preceding CRL. For each CRL, the issuer's certificate may be supplied. A certificate in the chain must belong to the issuer of the immediately preceding CRL. The relationship between a certificate and an immediately preceding CRL is the same in both cases. In a <certchain> the crl's are optional. In a <crlchain>, the certificates are optional. 6. Message Composition When a user composes a message, it is the responsibility of the user agent to construct a valid MIME message. In particular, Content-Type: and Content-Transfer-Encoding: headers should be used wherever they are appropriate. This allows the receiving user agent to unambiguously interpret the Expires Apr, 1994 [Page 10] draft MIME-PEM Interaction Oct 1993 message body and process it accordingly. Each block of content headers associated with either an RFC822 <message> or with a MIME <body-part> represents a logical place where privacy enhancement can be requested. A privacy enhancement request associated with a particular <message> or <body-part> content is taken to apply to the entire content; it is not possible to privacy-enhance only a portion of a body part. The mechanism used to communicate privacy enhancement requests to the pre-submission processor described below is strictly a local implementation issue. However, the interface between the message composer and pre-submission processing MUST be trustworthy, since the message composer relies on pre- submission processing to either perform the requested privacy enhancement operation or return an error. Regardless of the mechanism chosen, great care should be taken to safeguard against both the release of information that has not received the requested type of privacy enhancement as well as tampering with the enhancement request itself. 6.1. Pre-Submission Algorithm The user agent first composes a MIME-compliant message and then applies this algorithm: (1) If the content at this (initially top) level has NOT been selected for privacy enhancement, the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content. (2) If the content at this level has been selected for privacy enhancement, then the content, including its headers, constitutes the object that receives privacy enhancement. The headers at a minimum will include a Content-Type header, either explicit or implicit. The object will eventually be replaced with the multipart/ Expires Apr, 1994 [Page 11] draft MIME-PEM Interaction Oct 1993 headerset content that is produced by the privacy enhancement operation. (3) The content of the object must be transformed from local form to its MIME binary canonical form. Also, if the requested privacy enhancement is signature, and if Content-Transfer-Encoding: headers were present in the headers of the object, the content encoding is reversed, leaving only 7BIT, 8BIT, and BINARY as possible encodings for all body parts. This is done so that any artifacts introduced by encoding are removed and consistent integrity checks will be generated. (4) Once an object in binary canonical form has been produced the selected privacy enhancement is performed. The privacy enhancement produces two data streams: the privacy enhanced object and a control stream comprised of a set of headers as defined in the <pemsig> or <pemkeys> productions. (5) A new body part is then constructed, of content type multipart/headerset. The body part contains two body parts, whose content depends on the privacy enhancement requested. (a) If the requested privacy enhancement is encryption, then the first body part within the multipart/ headerset is labelled with a content type of application/pem-keys and contains the <pemkeys> control stream produced by the privacy enhancement. The second body part within the multipart/headerset is labelled with a content type application/pem- encrypted, and contains the privacy enhanced object produced by the privacy enhancement. An appropriate transfer encoding is also applied to the content and a corresponding Content-Transfer-Encoding: header is added to the application/pem-encrypted body part. Base64 encoding is recommended in the case of encryption privacy enhancement in order to be backwards-compatible with the original PEM conventions. (b) If the requested privacy enhancement is signature, then the first body part within the multipart/ headerset is labelled with a content type of Expires Apr, 1994 [Page 12] draft MIME-PEM Interaction Oct 1993 application/pem-signature and contains the <pemsig> control stream produced by the privacy enhancement. The second body part within the multipart/headerset is labelled with a content type application/quoted- mime-entity, and contains the privacy enhanced object produced by the privacy enhancement. An appropriate transfer encoding is also applied to the content and a corresponding Content-Transfer-Encoding: header is added to the application/quoted-mime-entity bodypart. This multipart/headerset content replaces the original object. 7. Post-Delivery Algorithm When a user receives a message containing a multipart/ headerset content, the user agent may transform the content back into its original form prior to privacy-enhancement. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm. When the original content is reconstituted into its MIME binary canonical form, it may use octet values outside of the US-ASCII repertoire and may contain body parts without line breaks. If the user agent replaces the multipart/headerset content with the original content, then it must select appropriate Content-Transfer-Encodings for each body part and add corresponding Content-Transfer-Encoding: headers. Upon successful completion of the post-delivery algorithm for each content, the type of privacy enhancement that was in effect for that content must be communicated to the user. The mechanism used to do this is a local implementation issue. As with requests for privacy enhancement to the pre-submission algorithm, the path between post-delivery processing and actual display of the message must be a trusted one, lest a message be presented that purports to have undergone some form of privacy enhancement it did not in fact receive. 8. Examples For example, suppose the following body part was selected for Expires Apr, 1994 [Page 13] draft MIME-PEM Interaction Oct 1993 privacy enhancement: Content-Type: message/rfc822 To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! After applying pre-submission algorithm with a request that signature privacy enhancement be applied to the body part, the body part submitted for delivery would appear as: Content-Type: multipart/headerset; boundary="Privacy Boundary" --Privacy Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Privacy Boundary Content-Type: application/quoted-mime-entity Content-Type: message/rfc822 To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! --Privacy Boundary-- After applying the post-delivery algorithm, the resulting body part would once again appear as: Expires Apr, 1994 [Page 14] draft MIME-PEM Interaction Oct 1993 Content-Type: message/rfc822 To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! The body part need not be ascii text. For example, the following audio body part could be privacy enhanced: Content-Type: audio Content-Transfer-Encoding: base64 JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj producing the following body part: Content-Type: multipart/headerset; boundary="Privacy Boundary" --Privacy Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Privacy Boundary Content-Type: application/quoted-mime-entity Content-Transfer-Encoding: 7bit Content-Type: audio Content-Transfer-Encoding: base64 JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj Expires Apr, 1994 [Page 15] draft MIME-PEM Interaction Jul 1993 --Privacy Boundary-- The following privacy-enhanced message illustrates how an enhanced body part can itself receive enhancement. Date: Mon, 29 Mar 93 13:57:08 -0500 From: Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US> To: Marshall Rose <mrose@dbc.mtview.ca.us> Subject: Forwarded integrity Message MIME-Version: 1.0 Content-Type: multipart/headerset; boundary="Privacy Boundary" --Privacy Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Privacy Boundary Content-Type: application/quoted-mime-entity Content-Type: multipart/mixed; boundary="Middle Boundary" --Middle boundary Content-Type: text/plain; charset=us-ascii The enclosed message was integrity enhanced. Greg V. --Middle Boundary Content-Type: multipart/headerset; boundary="Forwarded Message" --Forwarded Message Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 Expires Apr, 1994 [Page 16] draft MIME-PEM Interaction Jul 1993 MIC-Info: RSA-MD5,RSA,... --Forwarded Message Content-Type: application/quoted-mime-entity Content-Type: message/RFC822 Date: Mon, 29 Mar 93 13:53:02 -0500 From: Ned Freed <ned@innosoft.com> To: Greg Vaudreuil <gvaudre@IETF.CNRI.Reston.VA.US> Subject: Minimal PEM Message This is a signed message using MIME-PEM. Greg V. --Forwarded Message-- --Middle Boundary-- --Privacy Boundary-- The following privacy-enhanced body part illustrates the use of encryption and the application/pem-encrypted content type. Content-Type: multipart/headerset; boundary="PEM Boundary" --PEM Boundary Content-Type: application/pem-keys Version: 5 DEK-Info: DES-CBC,4C776432D61A9829 Originator-ID-Asymmetric: ...,09 Key-Info: RSA,... --PEM Boundary Content-Type: application/pem-encrypted Content-Transfer-Encoding: base64 8R/EVhZy7OU= --PEM Boundary-- Expires Apr, 1994 [Page 17] draft MIME-PEM Interaction Jul 1993 If it was desired to produce a signed and encrypted body part, the signature would be done first, producing: Content-Type: multipart/headerset; boundary="Sign Boundary" --Sign Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Sign Boundary Content-Type: application/quoted-mime-entity Content-Type: message/RFC822 To: Ned Freed <ned@innosoft.com> Subject: Strongly Protected Message This will be signed and encrypted. Let the bad guys do their worst! Jim --Sign Boundary-- and then it would be encrypted, producing: Content-Type: multipart/headerset; boundary="Enc Boundary" --Enc Boundary Content-Type: application/pem-keys Version: 5 DEK-Info: DES-CBC,4C776432D61A9829 Originator-ID-Asymmetric: ...,09 Key-Info: RSA,... --Enc Boundary Expires Apr, 1994 [Page 18] draft MIME-PEM Interaction Jul 1993 Content-Type: application/pem-encrypted Content-Transfer-Encoding: base64 9S/FWjAz8P=V --Enc Boundary-- where the encrypted contents, 9S/FWjAz8P=V, are the encryption of the first multipart/headerset. 9. Observations The use of the pre-submission and post-delivery algorithms to combine PEM and MIME capabilities exhibit several properties: (1) It allows privacy-enhancement of an arbitrary content, not just an entire RFC 822 message. (2) For a multipart or message content, it allows the user to decide whether the structure of the content should receive what sort of privacy-enhancement. (3) It provides for messages containing several privacy enhanced contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components. The use of a MIME-capable user agent makes complex nesting of enhanced message body parts much easier. For example, the user can separately sign and encrypt a message. This motivates a complete separation of the confidentiality security service from the authentication/message integrity security service. That is, different keys could be used for the different services and protected separately. In the asymmetric case, this means an employee's company could be given access to the (private) decryption key, granting the company the ability to decrypt messages addressed to the employee in emergencies, without also granting the company the ability to sign messages as the employee. Expires Apr, 1994 [Page 19] draft MIME-PEM Interaction Jul 1993 The use of two private keys requires the ability to maintain multiple certificates for each user. 10. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. 11. References [1] D.H. Crocker, Standard for the Format of ARPA Internet Text Messages, RFC 822, August, 1982. [2] N. Borenstein, N. Freed, Multipurpose Internet Mail Extensions, RFC 1341, June 1992. [3] J. Linn, Privacy Enhancement for Internet Electronic Mail -- Part I: Message Encryption and Authentication Procedures, RFC 1421, DEC, February 1993. [4] S. Kent, Privacy Enhancement for Internet Electronic Mail -- Part II: Certificate-Based Key Management, RFC 1422, BBN, February 1993. [5] D. Balenson, Privacy Enhancement for Internet Electronic Mail -- Part III: Algorithms, Modes, and Identifiers, RFC 1423, TIS, February 1993. [6] B. Kaliski, Privacy Enhancement for Internet Electronic Mail -- Part IV: Key Certification and Related Services, RFC 1424, RSA Laboratories, February 1993. [7] R. Braden, Editor, Requirements for Internet Hosts -- Application and Support, RFC 1123, October 1989. 12. Author Addresses Steve Crocker Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 email: crocker@tis.com Expires Apr, 1994 [Page 20] draft MIME-PEM Interaction Jul 1993 Ned Freed Innosoft International, Inc. 250 West First Street, Suite 240 Claremont, CA 91711 USA Tel: +1 909 624 7907 Fax: +1 909 621 5319 email: ned@innosoft.com Jim Galvin Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 email: galvin@tis.com Sandra Murphy Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 email: murphy@tis.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 Tel: +1 415 968 1052 Fax: +1 415 968 2510 email: mrose@dbc.mtview.ca.us Expires Apr, 1994 [Page 21]